Smart cards can be used to authenticate a user, for example, when the user logs into a network and/or computing system. Smart cards can provide a strong form of authentication from the use of cryptography-based identification and proof of possession when authenticating the user. Smart card authentication is a two-factor authentication method in that (1) a user presents a smart card, and (2) the user provides a personal identification number (PIN). In the case of smart cards, a malicious person would have to obtain both the smart card of the user and the PIN of the user to impersonate the user.
FIG. 1 is an example of conventional prior art system architecture 100 for authenticating a user 101 via a local smart card 103. A user 101 that attempts to log on to a computer (e.g., computing machine 120) generally enters the user's credentials, which are used to verify the user's identity. For smart card logons, a user's credentials and/or one or more values derived from the user's credentials are contained on the security chip of the smart card 103, which is read by a device, such as a smart card reader. A user 101 can insert a smart card 103 into a smart card reader associated with a computing machine 120, and a Windows® logon service (WINLOGON) 121 prompts the user 101 to enter a PIN (rather than a username and password) as input via a graphical user interface being displayed on the computing machine 120. WINLOGON 121 can reside on the computing machine 120, which is the same computing machine 120 that is coupled to the smart card 103, to authenticate the identity of the user 101 to allow the user 101 to log into an operating system (e.g., Windows® operating system) and/or applications that may be executing on the computing machine 120.
WINLOGON 121 can pass the PIN to an LSA application programming interface (API) 123 to communicate to the Local Security Authority (LSA) 126. The LSA 126 is a protected system process that can authenticate and log users (e.g., user 101) on to the computer (e.g., computing machine 120). The LSA 126 can include a subsystem, Local Security Authority Subsystem Service (LSASS) 127, that is responsible for enforcing the security policy on the system (e.g., computing machine 120). The LSASS 127 can verify users (e.g., user 101) logging on to a computing system 120 (e.g., Windows® computer) or a server. The LSASS 127 can be a process in an operating system (e.g., Windows® operating system).
The LSASS 127 can create an access token for an authenticated user. The PIN can be passed to the LSASS 127, which can generate and return an access token. The access token can be used to impersonate an authenticated user (e.g., user 101).
The logon information to authenticate the user 101 with a domain controller 122 can be stored in an encrypted format on the smart card 103. The smart card 103 can contain a microprocessor and non-volatile memory that stores the user's logon information, private key 108, digital certificate 105 that includes a public key 107, and other private information. A public key infrastructure (PKI) can create secure communications. PKI is asymmetric in that a key pair is used to create the secure communications. A public key 107 of the user 101 can be used to encrypt data and a private key 108 of the user 101 can be used to decrypt data. PKI uses digital certificates (e.g., certificate 105) that include a public key 107 of a user 101 for encrypting data. The public key 107 can be made publicly available to one or more entities (e.g., domain controller 122) for creating secure communications with a respective entity. The private key 108 is not made publicly available, and is kept secret by the owner (e.g., user 101).
The LSA 126 can use the PIN to access the smart card 103. The LSASS 127 can issue one or more program calls (e.g., smart card API calls 124) to the native smart card API 125 (e.g., native Windows® Smart Card (WinSCard) API) to interact with the local smart card 103 to obtain the certificate 105 containing the public key 107 from the smart card 103. The native smart card API 125 (e.g., WinSCard API) is used by applications to interact with smart cards (e.g., smart card 103). The LSASS 127 can pass the PIN to the smart card 103 via the smart card API calls 124 made to the native smart card API 125.
The smart card 103 can confirm that the PIN is valid if the smart card 103 can use the PIN to successfully decrypt the user's logon information that is stored on the smart card 103. If the PIN is valid, the smart card 103 allows the LSASS 127 to obtain the certificate 105 containing the public key 107 that is stored on the smart card 103 via the native smart card API 125. The certificate 105 can be an X.509 (e.g., X509 v3) certificate. In some implementations, if the PIN cannot successfully decrypt the user's logon information for a number of times, for example, because the PIN is incorrect, the smart card 103 is locked.
The LSASS 127 can send the user's certificate 105, which contains the user's public key 107, along with other user information to a domain controller 122 as pre-authentication data in an initial authentication request. The domain controller 122 can validate the certificate 105, extract the public key 107, and use the public key 107 to encrypt a logon session key. The domain controller 122 returns the encrypted logon session key to the computing machine 120. If the computing machine 120 is in possession of the private key 108 of the user 101, the computing machine 120 can use the private key 108 to decrypt the logon session key. The computing machine 120 and the domain controller 122 can use the logon session key in further communications between each other.
This traditional mechanism can only be used for local smart card authentication, where the smart card and authentication server reside on the same computing machine. If the user 101 needs to access an operating system and/or applications on a remote computing machine, the described mechanism cannot provide for remote smart card authentication.
As described above, current solutions utilizing the LSA Subsystem Service (LSASS) do not provide for remote smart card authentication. Remote Desktop Protocol (RDP) is known to be used in a Remote Desktop Services (RDS) environment to authenticate remote smart cards. Remote Desktop Services (RDS) is a Microsoft® component that allows a user to take control over a remote computer or virtual machine over a network connection. A Remote Desktop Session Host (RDSH) server is an RDS component that hosts Windows® based programs or a full Windows® desktop, which remote RDS clients can access. Users can connect to an RDSH server to run programs, to save files, and to use network resources on that server. Remote Desktop Protocol provides a user with a graphical interface to connect to an RDSH server over a network. A smart card can be used to remotely authenticate a user to an RDSH server.
FIG. 2 is an example of conventional prior art RDS system architecture 200 for providing, using RDP, remote smart card authentication to provide a user with access to applications on an RDSH server. Users (e.g., user 201) can connect, via RDS clients (e.g., client device 210) and an RDP connection 240 over network 250, to an RDSH server 230 hosted on a computing system 220 to run applications 231 or full desktops hosted on the RDSH server 230. For example, the applications 231 may include an email application, a word processing application, a spreadsheet application, a presentation application, etc. that may be used by one or more users 201 and client devices 210.
In order to provide RDS, there needs to be the RDP connection 240 between the client device 210 and the RDSH server 230 to allow the client device 210 to access the applications 231 being hosted by the RDSH server 230. For security reasons, the user 201 needs to be authenticated to the RDSH server 230 before logging into an RDP session. Traditionally in a Windows® 2003 environment, a user 201 must first establish the RDP connection 240 between the client device 210 and the RDSH server 230 prior to authenticating with the RDSH server 230. The user 201 can initiate the RDP connection 240 via a graphical user interface (GUI).
Logging into an RDP session using simply a user name and password generally does not provide strong authentication and may not satisfy, for example, a company's security policies. To help strengthen security, there may be a need to replace the traditional mechanism of using a user name and password for logging into an RDP session with a more robust form of authentication, such as remote smart card authentication.
Some traditional technology, such as Network Level Authentication (NLA), can allow the user 201 to be authenticated via the remote smart card 203 before an RDP connection 240 is established. NLA is a technology used in Remote Desktop Services or Remote Desktop connection that requires the connecting user (e.g., user 201) to be authenticated before a session is established with the server (e.g., server 230). NLA uses Credential Security Support Provider protocol (CredSSP), and requires that CredSSP be enabled in a system registry. The operating system of the client device (e.g., client device 210) has a CredSSP client component and the server (e.g., server 230) has a CredSSP server component. NLA delegates the user's credentials from the client through CredSSP client component and prompts the user (e.g., user 201) to authenticate before establishing a session on the server (e.g., server 230). NLA, however, is a limited solution in that NLA does not support other credential providers.